fix: prevent silent errors during SSO (account settings) - #38673

Thanks for the pull request, @Gi-ron!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform-oncall.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

Hi @Gi-ron! It looks like you're contributing on behalf of eduNEXT. In order to have your CLA check turn green, please have your manager reach out to oscm@axim.org to have you added to our existing entity agreement.

Hi @Gi-ron! It looks like you're contributing on behalf of eduNEXT. In order to have your CLA check turn green, please have your manager reach out to oscm@axim.org to have you added to our existing entity agreement.

Thank you! I appreciate it.

I've already been enrolled in the CLA, so I'll keep an eye on the PR and wait for the status to update. Thanks again for your comments!

@Gi-ron also, this PR needs at least one test

@Gi-ron also, this PR needs at least one test

I added two tests: one for the cases where exceptions are processed in the middleware, and another for the cases where legacy_urls constructs the redirect URL.

Hi @igobranco, @felipemontoya @bra-i-am, @jignaciopm

I’ve added some changes to enable rendering error messages in the Account MFE, along with additional tests.

The main idea is to capture as many python-social-auth exceptions as possible. Unfortunately, at the moment the Account MFE only renders a user-facing message for duplicate_provider.

Could you please take a look at the changes and give me your feedback? It would be really helpful. Thanks in advance!

Hi @Gi-ron, thanks for the PR — the problem statement is correct. A couple of suggestions before this moves forward upstream.

The exception mapping may be unnecessary

SocialAuthExceptionMiddleware.process_exception (the parent of openedx's ExceptionMiddleware) already calls messages.error(request, message, extra_tags=f"social-auth {backend_name}") for every SocialAuthBaseException — including AuthAlreadyAssociated. The TPA_ERROR_CODES mapping and the custom session keys replicate something the framework already does.

There is an accepted ADR for this

ADR-0029 (Standardize Error Responses, accepted 2026-03-31) defines exactly how errors should reach MFEs. The relevant field is user_message:

"a human-readable, translatable string intended for display in MFEs or end-user UIs. Use user_message when the server must supply context that cannot be expressed by type alone."

The TPA case is precisely this — the provider name is context that type alone cannot express. The standard shape for this error would be:

{
  "type": "https://docs.openedx.org/errors/tpa/already-associated",
  "title": "Third-Party Account Already Linked",
  "status": 409,
  "detail": "AuthAlreadyAssociated: tpa-saml",
  "user_message": "The Cartão de Cidadão account you selected is already linked to another account.",
  "instance": "/auth/login/tpa-saml/"
}

Suggested alternative

Rather than URL query params, a small endpoint exposing the existing Django message as JSON (consumed on read — flash semantics built in) would let the Account MFE call it once on mount and render a generic user_message alert. No duplicate_provider param, no tpa_error_code, no TPA-specific logic in the frontend — and any future backend message surfaces automatically.

This would also align the fix with ADR-0029 rather than establishing a parallel convention that diverges from the platform standard.

Thanks for pivoting to the endpoint-based approach, @Gi-ron — this looks much cleaner and matches ADR-0029 well. A couple of small things to close out before this is ready to merge:

1. PR description is stale. It still describes the old ?duplicate_provider= query-param redirect and the screenshot is presumably from that version too. Could you update the description (and re-take the screenshot if needed) to reflect the current ThirdPartyAuthErrorMessageView / user_message design? Reviewers coming in fresh will otherwise get the wrong mental model of what this PR does.

2. Frontend dependency. This PR adds the v1/accounts/third_party_auth_error/ endpoint, but as far as I can tell nothing in frontend-app-account calls it yet. Do you have a companion PR there that polls this endpoint on mount and renders user_message? If not, this fix won't actually surface anything to users until that lands — worth linking it here (or opening it) so we can track both halves together.